OpenEdge Development:<br />Progress Dynamics Administration Designing upgrade programs

Because of how the DCU processes upgrades, all upgrade programs must conform to the following requirements:

Runs non-persistent — An upgrade program runs non-persistently. The DCU acquires a schema lock on the databases it is updating during Phase 1. Persistent procedures with database access code might cause problems when .df files are loaded. If an upgrade program invokes any persistent procedures, especially ones that access the database, the upgrade program must also shut down those procedures.

Uses no parameters — An upgrade program takes no parameters.

Runs without user interaction — Upgrade programs run as background procedures in a noninteractive mode. There can be no user interaction inside an upgrade program.

Generates a RETURN at completion — All upgrade programs should end the main block with either a RETURN or a RETURN ERROR.

Upgrade fails on RETURN ERROR — When an error condition is raised and returned to the DCU, the DCU treats it as a failed condition. The DCU stops processing and quits the upgrade. This is an extreme way to end an upgrade program and should only be used for fatal errors. RETURN ERROR should only be used to end the upgrade process.

Writes to the log file — The log file is the only recording of what took place during a DCU session. Therefore, it is very important that status information is regularly written to the log file. You can update the log file using a PUBLISH statement as follows:


`PUBLISH "DCU_WriteLog":U ("Message")`

Handle schema triggers — In general, it is not good practice to override schema triggers. Overriding the triggers can result in data problems. However, there are certain cases where you must override the triggers, such as with upgrade programs that run without the complete Progress Dynamics framework during Phase 1. In these cases, the upgrade program should perform the tasks that the schema triggers would normally perform. You must supply defaults for information that the triggers would normally obtain through calls to managers.

Handle cache issues — During Phase 2, remember that the Progress Dynamics environment caches data in many places. Loading ADOs can invalidate the existing caches. Any of your upgrade procedures that make use of the framework’s cached data should refresh the cache before using it. This should correct problems caused by upgrade procedures that ran before it.